Various electronic mechanisms are used for storing data which multiple parties need to access, modify and/or maintain, including electronic ledgers and database managements systems.
A ledger may be a collection of entries (obligations, assertions, debts, credits, etc.) in a notebook or other physical or electronic form and are akin to a transaction log whereby the current “state” of a ledger may be ascertained by netting or otherwise totaling all of the entries up to the current time period. For example, “Party A loans $X to Party B” could be an entry representative of a transaction in a ledger. “Party B repays $X to Party A” may be a subsequent entry of another transaction in that ledger. The net result of these two entries is the extinguishing of the debt of B to A. Ledgers typically utilize double-entry book keeping whereby separate ledger entries, or separate ledgers, are maintained for each side (account/party) to a transaction and transactions are recorded as a pair of opposing transactions, e.g. credits vs. debits, to each respective account/party, either in the same ledger or in separate ledgers, each maintained by the respective party.
Ledgers may be held by individual parties, or ledgers may contain entries for multiple parties and be replicated/distributed amongst a variety of sources. A ledger which comprises many distributed copies may be referred to as a replicated ledger. An example of an electronic replicated ledger is the “blockchain” methodology employed, for example, by the Bitcoin digital currency. Blockchain is an electronic public replicated ledger in which transactions, such as those involving the cryptographic currency Bitcoin, are recorded.
A blockchain database is implemented by software, which may be referred to as blockchain software, which is executed by each computer client, which may be referred to as a node or miner, which is participating in the particular overall system, e.g. digital currency payment system, for which the data stored in the blockchain is being used, e.g. to track payments of digital currency, etc. Generally, the software running on each node maintains a copy/replica of the blockchain data/database. The combination of the blockchain database and the software which maintains it may collectively be referred to simply as a blockchain or a replicated blockchain. The data stored in a blockchain is typically coalesced, collected or grouped together, such as on a quantitative and/or periodic basis, into blocks where each block is coupled or linked, such as in a cryptographic manner, with a prior block forming a chain of blocks which may continue to grow as new data is added.
Each of the replicated blockchains communicates with the others via a network, such as the Internet. It will be appreciated that the term network, in addition to referring to the communications medium by which replicated blockchains communicate, may also be used to refer to the collection of blockchain clients which are implementing a particular system using a blockchain database for data storage and other functions, which may also be referred to as a blockchain network, or for example, in the case of the Bitcoin implementation of a blockchain, the Bitcoin network.
The blockchain software further implements particular rules for allowing/validating modifications, e.g. addition of new transactions, to the blockchain database by the operator of the particular client as well as for validating and implementing modifications to the blockchain database received from other clients. These rules are generally defined by the type of system the blockchain network is being used to implement, e.g. a system for payment of digital currency, and are coded into the software. In order to change these rules, the software must be updated.
For example, one implementation of a blockchain network is Bitcoin which is a system for digital payment transactions, which may be referred to as the Bitcoin network. Generally, users wishing to make or receive payments of a digital currency, called Bitcoin, construct transaction messages which document a transaction, e.g., the payee, the payor, the amount to be paid/received, source(s) of funds, a script detailing a cryptographic authentication from one or more parties authorized to allocate the funds, etc. The transaction is then submitted to the Bitcoin network for validation, e.g. to confirm available funds, authenticity of the payor, etc. Each node of the network receives the transaction and executes the rules implemented by the Bitcoin blockchain software to validate the transaction, e.g. ensure the payor has unspent funds (calculated from previous unspent transaction outputs) to cover the transaction and that no one is trying to spend the same Bitcoins twice, and then, if validated, record it in the blockchain database and notify other nodes of the modification thereto.
A blockchain network may include miners and nodes. A node may contain a portion of the blockchain (partial node) or the whole blockchain (full node). The node may be configured to check if new transactions are acceptable, and or for example, to check that number of Bitcoins that currently are available for an address. A miner may be configured as a separate entity or as a node as above (with complete or partial data of the blockchain) that creates new blocks that confirm transactions. The new blocks, if found by a miner, are added to the blockchain and are made available (published) on the nodes. Miners are configured to find the new blocks using an algorithm and earn a reward for found blocks. Miners are thus incentivized and rewarded for their effort via the award of a defined amount of Bitcoins for being the first to complete the validation/blockchain modification process, which, by design is a non-trivial process. A blockchain network may include a plurality of miners, a plurality of nodes, and a plurality of mining nodes, e.g. nodes that are also configured as miners. The plurality of nodes may run node software, the miners may run mining software, and the mining nodes may run a combination of the node and mining software. The term “blockchain client” may be used herein to describe miners, nodes, or mining nodes. The term “blockchain software” may be used herein to describe mining software, node software, or mining node software.
In particular, in the Bitcoin blockchain, a block may only be added by solving a cryptographically defined computation based on the data to be stored in the block, data related to the prior block and an arbitrary value selected by the miner with a result of the computation having to meet specific requirements in order to be accepted. As the necessary computations take time and it may take many attempts by the miner to achieve a suitable result, in conjunction with the reward for success, the Bitcoin blockchain creates a competitive environment in which miners compete, e.g. using computing power, to be the first to successfully add a new block to the blockchain.
The Bitcoin blockchain operates completely transparently, so all data is transmitted to, and is readable by, all participants in the Bitcoin system. That is, each party in the Bitcoin system, with some exceptions, maintains a copy of the ledger, stored by the blockchain, in which all transactions are recorded, referred to as “full replication.” In the case of Bitcoin, this replicated ledger makes all transactions “open transactions” and viewable by all participants on the blockchain network and is a necessary property required to prevent double spending of Bitcoins, i.e., parties attempting to send the same Bitcoin to multiple parties. This property of visibility of all transactions in the Bitcoin network is also a drawback of a blockchain, because it does not allow for the confidentiality of transactions. Every participant in the Bitcoin network has access to every transaction on the blockchain. This facilitates the ability to track digital assets, e.g. Bitcoins. The integrity of transactions recorded in each ledger may be cryptographically protected, i.e. “signed,” via a transacting party's or parties' privately held cryptographic key(s). The transactions of funds from an address may require authorization from one or more parties that may sign, e.g. give authorization, through use of one or more cryptographic keys. In certain transactions, multiple parties may be required to authorize allocation of funds. For example, for a multi signature address, two or more parties may be required to authorize allocating funds from the address. Additional, more complex options may require certain conditions to be met for one of the two or more parties to provide authorization. In an example, a multi signature address may require that two out of three parties authorize transactions, or three out of five, or five out of seven, etc. In a scenario that only a single signature is used, if someone were to steal a blockchain/Bitcoin user's private key, the thief could have all of the information necessary, e.g. the transactional record and a cryptographic key thereto, to be able to see all of the transactions to which the user is a party, and the thief would be able to create transactions using the private key without the true owner of the private key's consent. Multiple signatures, as described above, may help prevent theft by requiring that the transaction be signed by multiple keys and as such require the thief to possess each key in order to authorize transactions.
Using the replicated ledgers of blockchain along with cryptographically linking/chaining the transactions stored therein enables all users to ensure the reliability of the transaction data, i.e. that transactions are recorded accurately and subsequent thereto, protected from alteration, as each user has a copy of all of the transactions and any unintended alterations to a transaction, e.g. via errors or fraudulent activity, are readily detectable via both the cryptographic discrepancies within the chained transactions that would be created as well as the discrepancies that such alterations will create among the various copies of the blockchain ledger.
Financial instrument trading systems are one example of complex systems that utilize databases according to a System of Record (“SOR”) model and which may be implemented using blockchain as described above. Generally, a financial instrument trading system, such as a futures exchange, referred to herein also as an “Exchange”, such as the Chicago Mercantile Exchange Inc. (CME), provides a contract market where financial instruments, for example futures, options on futures and spread contracts, are traded among market participants, e.g. traders, brokers, etc. Futures is a term used to designate all contracts for the purchase or sale of financial instruments or physical commodities for future delivery or cash settlement, and which are traded on a commodity futures exchange. A futures contract is a standardized legally binding agreement to buy (long) or sell (short) a commodity or financial instrument at a specified price at a predetermined future time. An option is the right, but not the obligation, to sell (put) or buy (call) the underlying instrument (for example, a futures contract) at a specified price within a specified time. The commodity or instrument to be delivered in fulfillment of the contract, or alternatively the commodity, instrument or reference for which the cash market price shall determine the final settlement price of the futures contract, is known as the contract's “underlying” reference, instrument or commodity, also referred to as the “underlier.” The terms and conditions of each futures contract are standardized as to the specification of the contract's underlier, the quality and quantity of such underlier, delivery date, and means of contract settlement, i.e. physical delivery or cash settlement. Cash Settlement is a method of settling a futures contract whereby the parties effect final settlement when the contract expires by paying/receiving the pecuniary loss/gain of the contract, e.g. by comparing the contract price to the market price or other reference price of the underlier at the time of settlement, related to the contract in cash, rather than by effecting physical delivery, i.e. the actual exchange of the underlying reference or commodity at a price determined by the futures contract.
Typically, the Exchange provides for centralized “clearing” by which all trades are confirmed and matched, and open positions are settled each day until expired (such as in the case of an option), offset or delivered. Matching, which is a function typically performed by the Exchange, is a process, for a given order which specifies a desire to buy or sell a quantity of a particular instrument at a particular price, of seeking/identifying one or more wholly or partially, with respect to quantity, satisfying counter orders thereto, e.g. a sell counter to an order to buy, or vice versa, for the same instrument at the same, or sometimes better, price (but not necessarily the same quantity), which are then paired for execution to complete a trade between the respective market participants (via the Exchange) and at least partially satisfy the desired quantity of one or both of the order and/or the counter order, with any residual unsatisfied quantity left to await another suitable counter order, referred to as “resting.”
A “Clearing House,” which is typically an adjunct to the Exchange and may be an operating division thereof, is responsible for settling trading accounts, clearing trades, collecting and maintaining performance bond funds, regulating delivery, and reporting trading data to market regulators and to the market participants. An essential role of the Clearing House is to mitigate credit risk via the clearing process. Clearing is the procedure through which the Clearing House becomes buyer to each seller of a futures contract, and seller to each buyer, also referred to as a “novation,” and assumes responsibility for protecting buyers and sellers from financial loss due to breach of contract, by assuring performance on each contract. A clearing member is a firm qualified to clear trades through the Clearing House.
Current financial instrument trading systems allow traders to submit orders and receive confirmations, market data, and other information electronically via a communications network. These “electronic” marketplaces, implemented by, and also referred to as, “electronic trading systems,” are an alternative trading forum to pit based trading systems whereby the traders, or their representatives, all physically stand in a designated location, i.e. a trading pit, and trade with each other via oral and visual/hand based communication.
In particular, electronic trading of financial instruments, such as futures contracts, is conducted by market participants sending orders, such as to buy or sell one or more futures contracts, in electronic form to the Exchange. These electronically submitted orders to buy and sell are then matched, if possible, by the Exchange, i.e. by the Exchange's matching engine, to execute a trade. Outstanding (unmatched, wholly unsatisfied/unfilled or partially satisfied/filled) orders are maintained in one or more data structures or databases referred to as “order books,” such orders being referred to as “resting,” and made visible, i.e., their availability for trading is advertised, to the market participants through electronic notifications/broadcasts, referred to as market data feeds. An order book is typically maintained for each product, e.g. instrument, traded on the electronic trading system and generally defines or otherwise represents the state of the market for that product, i.e. the current prices at which the market participants are willing to buy or sell that product. As such, as used herein, an order book for a product may also be referred to as a market for that product.
In a futures exchange both trading and clearing may operate under a Central Counter Party (“CCP”) model, where the futures exchange functions as a counter party to each trade and to the clearing of each trade, referred to above as a novation. CCPs benefit both parties in a transaction because the parties bear most of the credit risk. In a scenario outside of a financial exchange, where two individuals deal with one another by themselves, the buyer bears the credit risk of the seller, and the seller bears the credit risk of the buyer. Conversely, when a CCP is used the credit risk that is held against both buyer and seller is coming from the CCP. One consequence of a CCP model is that all communication and transactions must flow through the CCP, i.e. the CCP is the SOR, and thus information and trading may only be as fast as the CCP may process it and transmit it out to the interested parties. Records are usually kept by the CCP in a database as the source of truth and communicated to other parties using messaging. The CCP's client, e.g. a clearing member, may further have its own database of at least a subset of these records and periodically, typically daily, may reconcile them with the CCP. Further, the customers of a clearing member may have their own database, necessitating similar reconciliation. This effectively serializes the distribution of data from the CCP to all interested parties and increases the latency thereof.
As will be appreciated, replicated electronic ledgers, such as blockchain, may be used to maintain transactional records reflecting trades, credit, payment etc. Examples of using such electronic replicated ledgers is disclosed in U.S. patent application Ser. No. 15/166,829, entitled “BILATERAL ASSERTION MODEL AND LEDGER IMPLEMENTATION THEREOF”, and Ser. No. 15/166,838, entitled “BILATERAL ASSERTION MODEL AND LEDGER IMPLEMENTATION THEREOF”, herein incorporated by reference in their entirety.